feat: add FormRequest for encapsulating validation and authorization#10087
feat: add FormRequest for encapsulating validation and authorization#10087michalsn wants to merge 3 commits intocodeigniter4:4.8from
FormRequest for encapsulating validation and authorization#10087Conversation
michalsn
added
new feature
paulbalandan
left a comment
paulbalandan
left a comment
There was a problem hiding this comment.
I find the same named class in Laravel useful before for focused request validation. If the functionality is similar to that, then I think it would be also beneficial here.
Some initial thoughts:
| * so their callable signatures cannot be expressed precisely in PHPDoc. | ||
| * | ||
| * @param string $from The route path (with placeholders or regex) | ||
| * @param array|Closure|string $to The route handler |
There was a problem hiding this comment.
how about Closure(mixed...): mixed?
There was a problem hiding this comment.
PHPStan would complain. A route closure that type-hints a FormRequest parameter doesn't match Closure(mixed...). This is a regression compared to what we had in PHPDocs... but I'm not sure if we can do something about it. Any suggestions are welcome.
|
Overall, this is a really nice feature to have. Most of the times, I have to create a final class which has static functions which return array of validation rules and call Validation service in controller. But looks like I have easier way to do that from 4.8.0. Thanks @michalsn |
|
You've started developing magic (autowire). It would be great not to limit yourself to one form and continue the idea. set the Autowire interface and any available class can be connected as in other frameworks. I think it can be done a long time ago. But the framework adheres to the rules from the 2000s =) Less obscure magic. Thus, we come to the need for DI/ServiceLocator, which is now replacing Services. You can view https://github.com/PHP-DI/PHP-DI as a separate package. |
|
I'm already making a similar object for validation myself, only directly |
Co-authored-by: John Paul E. Balandan, CPA <paulbalandan@gmail.com>
|
@paulbalandan I took the idea for this directly from Laravel. |
|
@neznaika0 Thanks for the feedback. Full DI container support is a legitimate feature in frameworks that prioritize that approach, but I don't believe it's the direction CI4 is going. That's not a weakness - it's more a positioning decision. |
|
That's the philosophy I'm talking about. I'm worried that subsequent similar improvements will use the same principle, but duplicate the logic. Right now, I can't say what would be useful to dynamically add to the controllers.. Everything is possible - Models, Services, Configs.. in the end, we come to DI =). I think that's why many people don't look towards CI, because they're used to magic SF, Laravel. Wordpress is an exception - it has a large community and allows non-standard approaches. |
That's a real concern. In fact Services are CodeIgniter answer to dependency management - explicit, overridable, and testable. They're not a DI container in the classical sense, but they serve the same purpose without the implicit magic. |
4 participants
Description
This PR introduces
FormRequest, an abstract base class that lets you move validation rules, custom error messages, and authorization logic out of controller methods and into a dedicated class. You type-hint the class in the controller signature, and the framework resolves, authorizes, and validates the request automatically before the method body runs.A
make:requestspark command scaffolds new classes. Injection works in both controller methods and closure routes, with route parameters resolved positionally alongside theFormRequest.I'd like your opinions on whether this belongs in the framework. Personally, I find it useful - once an app grows, controllers tend to fill up with validation boilerplate.
FormRequestmoves that out, keeps controllers focused on the "happy path", and makes the rules reusable across endpoints.Checklist: